REMARKS 

Claims 1-21 are pending the above-mentioned application. The Office Action has allowed 
claims 2-6, 9, and 13-15. Claims 7, 8, 10-12, and 16-21 are objected to. In addition, the drawings 
are objected to. 

More particularly, claim 1 has been rejected under 35 U.S.C. 102(e) as being anticipated 
by Hu, U.S. Patent No. 6,230,226, which is directed to a compound device implementing hub 
and function endpoints on a single chip. The Office Action has alleged that the configuration 
module, recited in claim 1, should be identified with items 41, 27, and 32 of the Hu reference. 
Item 41 is described as a decoder, item 27 as a function address register and item 32 as a 
multiplexer. Applicant respectfully submits that these items are do not meet the limitation "a 
configuration module for configuring, without the need of a CPU, the communication channel 
between the slave device and the host device," as recited in claim 1 , because they still require the 
use of the host CPU 20, in Hu, to configure the device controller. As the Hu reference states, 
"[t]he back interface, and in particular, decoder 41 must handle the special case of enumeration. 
During enumeration, the addresses of all devices are set to a common starting address. Thus, 
during enumeration, the address for the function endpoint 52 and the hub endpoint 51 will be the 
same. Accordingly, the hub address register 26 and the function address register (27), will also be 
the same." Hu '226, Col. 2, line 63 to Col. 3, line 2. As far as Applicant can determine, this 
enumeration is being carried out by the host 20, according to the USB convention. Therefore, Hu 
does not meet the limitation recited above because the host is involved in the enumeration. The 
only function of the backend interface and decode is to determine when a packet is destined for 
the hub endpoint or the function endpoint, as they share the SIE. Hu Abstract. Thus, Applicant 
believes that claim 1 is allowable. 

With respect to objected-to claims 7, 16, 18, 20, Applicant, in the interests of putting 
these claims in good form for allowance, has rewritten these claims to include the limitations of 
claim 1, from which they depended. However, Applicant has struck the limitation "without the 
need of a CPU" from these claims, because it is believed that the limitations of claims 7, 16, 18, 
and 20 are sufficient to make these rewritten claims allowable. 
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With respect to objected-to claims 8, 10-12, Applicant believes that claims 8, 10 and 12 
are allowable as they depend from rewritten claim 7 and that claim 1 1 is allowable as it depends 
from claim 10. 

With respect to objected to claims 17, 19, and 21, Applicant believes that these claims are 
allowable as being dependent from rewritten claims 16, 18 and 20, respectively. 

Applicant has amended the drawings to move the objected to material into the 
specification, in accordance with the request of the Examiner. A revised specification and 
drawings accompany this response. 

For these reasons, and in view of the above amendments, this application is now 
considered to be in condition for allowance and such action is earnestly solicited. 



Respectfully Submitted, 



Dated: April 20, 2004 



DECHERT LLP 
Customer No. 37509 

P.O. Box 10004 
Palo Alto, CA 94303 
Telephone: 650.813.4800 
Facsimile: 650.813.4848 



Anthony Diejienbrock III, Esq 
Attorney for Applicant 
Reg. No. 39,960 
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USB DEVICE CONTROLLER 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is a continuation-in-part of application 5 4 208 28 fil e d on 
, having SN and is incorporat e d by r e f e r e nc e h e r e in l J.S. Patent 

Application. Serial Number 09/191.443. filed o n November 12. 1998, titled A Universal Serial 
BUS (X JSB^ RAM Architecture for use with Microcomputers via an Inte rface Optimized for 
Integrated Services Device Network rtSDTSH which is now U.S. Patent No. 6.219.736 BL issued 
on April 1 7. 2001 . which patent is incorporated herein bv reference . 

This application is related to an application entitl e d "CONFIGURATION 
SELECTION FOR USB DEVICE CONTROLLER", filed on — rU.S. Patent 
Application Serial Number 09/670.509. filed September 26. 2000. t itled Configuration Selection 
for USB Device Controller. 

FIELD OF THE INVENTION 

This invention relates generally to a device controller for a standardized bus and 
more particularly to an device controller for a USB device. 

DESCRIPTION OF THE RELATED ART 

The proliferation of the personal computer has spawned a large market for 
peripheral devices for these personal computers. To attach these peripheral devices an interface 
bus, the ISA bus was developed. This bus required that a printed circuit board be attached to the 
bus which was accessible only by opening the personal computer system-Is housing. Although 
this means of attaching peripheral devices worked well, there were driver and resource sharing 
problems that led to the development of a higher-speed, internal bus, the PCI bus, and a lower 
speed external bus, the Universal Serial Bus (USB), which is designed to multiplex low-speed 
device transfers over a single pair of wires operating bidirectionally and requires only minimal 
resources from the system that hosts the USB. 

The USB is a serial cable bus that supports packet-based transactions between a 
USB Host and one or more USB Devices. At the highest level, USB Devices implement one or 
more application-specific functions by means of USB interfaces, one for each function. A USB 
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interface includes one or more endpoints, where an endpoint is an addressable part of a device 
that acts as the sender or receiver of a transaction. The USB Host communicates with the 
endpoints of the USB device through pipes and each endpoint and pipe support certain control 
and data transfer types Thus, a USB Host sees a USB Device as a collection of interfaces and 
pipes. However, the interfaces of a USB device must be configured and made known to the USB 
host and configuring a USB device requires a that the USB device handle a complex high-level 
protocol on top of the packet-based transactions. 

The USB system has brought forth several new types of interface devices for 
adapting a peripheral to the high-level protocols of the USB. Some of these types are a USB-to- 
clocked-serial interface, USB-to-FIFO and embedded USB in a microcontroller. In addition, 
special purpose interface devices are available which include USB-to-Ethernet, USB-to-Floppy 
Disc Controller, USB-to-EEE parallel port, USB-to-Scan controller, USB-to-Keyboard, USB-to 
Audio Codec, and USB-to- AT API devices. These devices typically include an 8-bit 
microcontroller that is programmed to handle the USB high-level protocols on the one hand and 
to manage the application specific interface on the other hand. These special purpose devices are 
usually produced in high volume and require a large design effort. 

To answer a lower- volume need, while still retaining a flexible interface, a 
different type of USB device controller was developed by the applicant. This device, a USB- 
RAM, is described in U.S. Patent A pplication No. (51208 00028), which is 

h e r e by incorporat e d hv r e f e r e nc e into th e pr e s e nt application. Serial Number 09/1 91 .443. filed on 
November 12. 1998. titled A Universal Ser ial BITS niSB^ RAM Archithctijrh for use with 

MlPROrOMPI ITERS VIA AN INTERFACE OPTIMIZED FOR INTEG RATED SERVICES DEVICE NETWORK (TSDNV nOW 

U.S. Patent No. 6.219.736 Bl. issued on April 17. 2001. USB-RAM device controller provides a 
general solution for connecting to the USB by providing an interface to the USB electrical bus 
and supporting the fixed protocol that is associated with all USB applications. The application 
specific aspects are handled by writing packets into a common memory and reading packets from 
the memory under interrupt control. 

FIG. 1 shows a block diagram of the USB-RAM device controller 8, which has two 
interfaces, one of which 10 connects to the USB D+ and D- lines and the other, a client processor 
interface 12, which has address, data and control lines for connecting to a local microcontroller 
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14. The USB-RAM device controller 8 includes a serial interface engine, SIE 16, for sending and 
receiving packets on the USB in accordance with the USB protocols and an interfacing device 18 
which comprises an endpoint register file 20, a common memory storage area 22 and control 
logic (not shown). The common memory storage area 22 includes data buffers 24 for holding 
operating data and data buffers 26 for transferring data between the function engine 14 and the 
USB interface 10. 

FIG. 2. shows a more expanded block diagram of the device controller 8 and in 
particular the common memory 22. According to the figure, the common memory storage area 22 
includes data buffers 30 used by the endpoints 20, an interrupt register image 32 and command 
register image 34, and an image area for the endpoint registers 36, 38 to allow the 
microcontroller to have access to the endpoint register file 20. 

FIG. 3 shows a representative endpoint register from the endpoint register file 20. 
The endpoint register 40 has a byte count field 42, a packet count field 44 for tracking how many 
packets are to be sent or received, a valid field 46 which determines whether the endpoint is 
valid, a type field 48 for holding the type of endpoint described by the register, a page number 
field 50 and index field 52 for accessing the common memory storage 22 of FIG. 1. 

Transfers to the USB host 28 in FIG. 1 occur when the local microcontroller 14 
connected to the client processor interface 12 writes a data packet into the common memory 22, 
sets up a packet pointer 50, 52 and a length counter 42 in the relevant endpoint register 40, 
checks to determine that the command register image 34 is cleared and then writes a send 
command into the command register image 34. The local processor 14 receives an interrupt that 
the data packet was sent on the USB to the host processor 28. 

Transfers from the USB host 28 in FIG. 1 occur by the host processor 28 sending a 
data packet on the USB bus to the device controller 18, which causes the data packet to be stored 
in the common memory 22 at a location specified by the relevant endpoint register 40 in FIG. 3. 
The local processor 14 connected to the client interface 12 of the device controller 18, receives 
an interrupt with an endpoint specific code that gives it notice that a packet has been received in 
the common memory 22. The local processor 14 then reads the interrupt code which identifies 
the endpoint, then reads the endpoint register image 38 to find the pointer 50, 52 to the packet 
and its length 44 and then reads the packet. A flag is set in the device controller to indicate to the 
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USB interface that the local processor 14 has read the data packet and is ready for another. Prior 
to setting the flag, auto-NAKS are generated to the USB host. 

However, the special purpose devices described above and the USB-RAM device 
controller as well suffer from a new problem because of a change to the USB specification. The 
speed of the USB, according to version 2.0, has increased greatly, from 12 MHz to 480 MHz. 
With this speed increase, it is very difficult for a local microcontroller or processor to keep up 
with the demands of the bus and handle the high-level protocol without slowing the bus down to 
an unacceptable speed. A protocol mechanism for slowing the bus down does exist (the auto 
NA &autoNAK mechanism) but using it is undesirable for a USB 2.0 type bus. 

Therefore, there is a need for a new USB device controller, one that provides a 
generalized and configurable solution to connecting to the USB and operates at speeds that will 
not slow down the USB running at 480 MHz. Furthermore, there is a need that such a device be 
available for low and medium volume applications, not involve a large design effort to bring to 
market and for the device to be flexible enough to support a number of useful configurations so 
that only one device is needed for the most common configuration cases. 

BRIEF SUMMARY OF THE INVENTION 

The present invention is directed to the foregoing needs. A device controller in 
accordance with the present invention includes a serial interface engine having a serial port for 
connecting to the serial bus and a data port. The serial interface engine generates and interprets 
packets on a serial bus that connects a slave device which includes the device controller and a 
function engine to a host device. The serial interface engine also transfers data between the serial 
bus and the data port. The device controller also includes an interfacing device connected 
between the data port of the serial interface engine and the function engine to transfer data 
between the serial interface engine and the function engine and includes a configuration module 
for configuring the communication channel between the slave device and the host device. 

The interfacing device includes at least one register for storing configuration 
information relating to a communication channel between the slave device and the host device 
and at least one memory for holding operating data relating to the communication channel. The 
configuration module is connected to the at least one memory and includes a plurality of finite 
state machines that are operative to receive and respond to a request from the host device. 

86401.3.17 

Page 4of22 4of28 

SV/101053.02 
091 32000/20: 1 1/5^20 8 .3 8 



5 4 208 38 



An advantage of the present invention is that the device controller keep pace with 
the high speed of the USB without stalling the host or the bus. 

Another advantage is that the interfacing device provides a uniform and low cost 
means for connecting a function engine to the USB SIE. 

Another advantage is that the configuration process, the most complex aspect of 
the USB device operation, is removed from the user^s responsibilities and built into a interfacing 
device. 



BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features, aspects and advantages of the present invention will 
become better understood with regard to the following description, appended claims, and 
accompanying drawings where: 

FIG. 1 shows the architecture of the USB-RAM device controller; 

FIG. 2 shows a more detailed block diagram of the USB-RAM device controller; 

FIG. 3 shows an endpoint register of FIG. 2; 

FIG. 4 shows a block diagram of an embodiment of the present invention; 

FIG. 5 shows a state machine system for configuring an interfacing device in 
accordance with the present invention; 

FIGs. 6A, 6B, 6C and 6D s e t forth a d e scription in a high level hardwar e mod e ling 
languag e of th e stat e machin e syst e m of FIG. 5; 

FIG. 2& shows a plurality of selectable state machines for implementing a 
configuration state machine; 

FIG. &Z shows a selection mechanism for selecting one of the plurality of state 
machines of FIG. 7£; 

FIG. 9& shows a plurality of selectable configuration state machines and a plurality 
of descriptor state machines; 

FIG. 4-02 shows an application of an embodiment of the present invention; and 

FIG. shows an additional application of an embodiment of the present 

invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

To understand the functions of the present invention, a portion of the USB packet, 
transaction and setup protocol is described below. 

The packet-based transactions on the USB through the pipes described above 
between the USB Host and USB Device consist of one or more packets transferred over the USB. 
All packets that can be transferred over the USB fall into three categories, (i) token, (ii) data or 
(iii) handshake packets. 

A token packet identifies the direction of a bus transaction, the address of the USB 
device, and the endpoint in the USB device involved with the host in the transaction, A data 
packet carries device specific data between the USB-Host and a device-Is endpoint. Lastly, a 
handshake packet is used to return flow control information for a bus transaction. 

The four types of information transfers, bulk, interrupt, isochronous and control, 
each employ the above packets types to carry out the transfer. For example, in a bulk transfer, the 
host sends a token packet, IN or OUT (where the direction is relative to the host), the data is then 
transferred in a data packet between the device and the host and finally a handshake packet, such 
as ACK, is delivered by the device or the host depending on the direction of the transfer, or a 
NAK or STALL is delivered by the device. The handshake packet ACK means that the data was 
transferred successfully. The NAK means that the device is not ready to transfer data and the 
STALL means that host intervention of the device is required, probably due to an error condition. 

An important type of information transfer is a control transfer. This type of transfer 
is used to configure and initialize a USB device, including its interfaces and endpoints. A control 
transfer has three Stages, each of which conforms to the token-data-handshake sequence. The 
three Stages are the Setup Stage, the Data Stage and the Status Stage. The token packet of the 
Setup Stage is called a Request and specifies a command sent from the host to the device via a 
special pipe, the Default Pipe. The Request has a well-defined structure that is described below. 
Any data needed beyond what is contained in the Request or any data returned by the device is 
sent during the Data Stage. The USB device returns a handshake packet in the Setup Stage with 
an ACK to accept the Request token sent by the host. 

As mentioned above there is a well-defined structure for a Request token. In 
particular, a Reques t, shown in Table A. is 8 bytes long having a request field (1 byte), a request 
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type field (1 byte), a value field 2 bytes), an index field (2 bytes) and a length field (2 bytes). 



Request Packet 


Field 


Size 


Description 


request_type 


1 byte 


Gives the request characteristics 


request 


1 byte 


the actual request 


value 


2 bytes 


data specific to the request 


index 


2 bytes 


information identifying a particular 
interface or endpoint, if the request is 
so targeted. 


length 


2 bytes 


length of a possible data stage 



Table A 

The request^ type field (Table B) determines the direction of any data stage 
associated with the request, the type of Request (Standard, Class, Vendor), and the type of target 
for the request (Device, Interface, Endpoint, Other). If the target is an interface or endpoint, then 
the index field is used to specifically identify that target. 



Request = type 


Bits 


Description 


7 


Direction of Data Stage (if there is one) 


5-6 


Type of request: 

STANDARD: 0 
CLASS: 1 
VENDOR: 2 
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0-4 


Type of Target: 




DEVICE: 0 




INTERFACE: 1 




ENDPOINT: 2 




OTHER: 3 


Tabi.f. B 



The value field is a two byte field that can hold a configuration value and the 
length field specifies the length of a data stage if the host needs to send more bytes than the value 
field can hold. 

There are 10 standard Request packets (Table C) a host device can send to a USB 
device. Included in the standard requests are GET_STATUS, GET_DESCRIPTOR, 
GET_CONFIGURATION, GETJNTERFACE, SET_ADDRESS, SETCONFIGURATION. 
These requests are briefly described below. 



Code 


Request 


0 


GETSTATUS 


1 


CLEARFEATURE 


2 


reserved 


3 


SETFEATURE 


4 


reserved 


5 


SETADDRESS 


6 


GETDESCRIPTOR 


7 


SET_DESCRIPTOR 


8 


GETCONFIGURATION 


9 


SETCONFIGURATION 


10 


GETINTERFACE 


11 


SETINTERFACE 



Tart.r C 
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- The GET_STATUS Request retrieves a two-byte bit map of the status for a device, 
interface or endpoint in the data stage of the request. The GET_DESCRIPTOR Request retrieves 
a specified type of standard descriptor from the USB device. There are five types of descriptors, 
(a) device, (b) configuration, (c) interface, (d) endpoint and (e) string descriptor. The 
GET_CONFIGURATION Request returns the current configuration value which is expected to 
be non-zero if the device is configured. The particular configuration is described by a 
configuration descriptor. The GETJNTERFACE Request returns the alternate setting for a 
particular interface. The SET_ADDRESS Request enables the host to assign an address to a USB 
device, which causes the device to enter the Addressed state from the Default state. The Default 
state is entered after the device is attached to the USB, powered up and reset. The 
SET_CONFIGURATION Request sends a configuration value to a device. Upon the successful 
receipt of the Request the device enters the Configured state from the Addressed state. A device 
can be de-configured by this command, in which case it returns to the Addressed state. 

As described above, for a USB Device to function according to the application- 
specific function which the device provides, the device must be configured. To become 
configured a USB Device must transition through several states. 

When the device is first attached to the USB the device is in the Attached state. 
From the Attached state the device enters the Powered state when power is applied following 
which it enters the Default State when reset is applied. In the Reset state the device responds only 
to address Oh and only the Default Pipe can be used by the host to access the device. The Default 
Pipe comprises a control endpoint that is bidirectional and this pipe is available before 
configuration. 

The host accesses the device via the Default Pipe to determine its description but 
must set the address of the device to a non-zero value before configuring the device. When a 
non-zero address is assigned, the device enters the Addressed state. From this state the host can 
then configure the device, which means establishing the interfaces and pipes of the device and 
their characteristics. The descriptors mentioned above are used to set and alter the configuration 
of a device and the standard descriptors are organized in a defined hierarchy that matches the 
configuration hierarchy of the device. Thus, there is a device descriptor, which characterizes the 
device as a whole, at least one configuration descriptor and descriptors for all of the interfaces of 
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that configuration. Finally, there are endpoint descriptors for each interface and there is a string 
descriptor for storing user-readable information in the device. A USB device must support the 
high-level protocol of descriptors to become configured and known to the USB host before it can 
perform the functions of the interfaces that it supports. 

Turning now to FIG. 4, a block diagram of an embodiment of the present invention 
is shown. Depicted in the block diagram are a serial interface engine (SEE) 16 which connects a 
USB device to the serial bus and which serializes and de-serializes packets on the bus for the 
device, and an interfacing device 60 that includes a USB control block 62 with an endpoint 
register file for the device, one or more dedicated memory blocks 66, 68, 70, 72, and one or more 
finite state machines including a setup module 74. A memory block 68, 70, 72 and an associated 
finite state machine (not shown) operate to support the functionality of an endpoint. In the 
embodiment shown, one memory block 66 associated with the configuration endpoint holds 
operating data. This memory block 66 preferably includes read-only memory for storing 
descriptor strings. Alternatively, the descriptor strings are stored in the fixed programming of the 
setup module 60, which is described in detail below. Another dedicated memory block 72 holds 
control information for an endpoint that supports interrupt pipe transfers and an associated finite 
state machine (not shown) interprets the command information sent beh^ means of the interrupt 
pipe transfers. Additionally, there are dedicated memory blocks for endpoints that support data 
transfers, one memory block 68 for the IN direction and one block 70 for the OUT direction. A 
function engine 76 that includes optional A/D and D/A circuitry and a FSM, for controlling the 
A/D and D/A circuitry, connects to the dedicated command, IN and OUT memories. 

The setup module facilitates the configuration of the USB device. 

THE SETUP MODULE 
The Srtup Module 

A block diagram of the SETUP Module, ADA_FSM 100, is shown in FIG. 5 and a 
high level hardware language description of the module is set forth in FIGs. 6A 6 Table D . 
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output; stall? 




id^token. dp 1 read, dp 1 write; 



fiftf.np_FSM I .dpdout (dndoiit.) . .elk (elk) 

■data (data), .mux (mux) .dp 
fRftt:_f.fikfin) . .valid token (valid token)): 

TNTERPRET_FSM 



. set^token 



interpret_FSM( .elk (elk) 

mux (mux) , ,sel (sel) 



.data (data), 



.stall 



•ip (descrip) 



.address (address), .confia 
DTK (DIR) , .STD (STD) , .etc. ) 



DESCRIP_FSM 



.descrip (descrip) 



M_daf.al . .dp_l read (dp 1 read) 
.reset: (reset) . .elk (elk) ) f 



CONFIGJFSM 




ata (c_dat:a) . . dp i read (dp 1 read) 
). .reset (reset), .elk (elk) ) ; 



FiSM (.a^data (a^data) , .dp^ljead (dp_l_read) , 
.address (address), .reset (reset), .elk (elk) ) ; 



always @ (posedae elk) beain: Out Mux: 
case (sel) 



iptor data. 




address data 
// select other appropriate data. 



endcase 
end 

wire r 7:0 1 dpdi = (usb M endpt == 0) ? AD oi 



Tabip. D 



The SETUP Module 100 includes two control state machines, SETUP_FSM 102 and 
INTERPRET_FSM 104, and one or more data delivering state machines, DESCRIP_FSM 106, 
CONFIG_FSM 108, ADDR FSM 1 10. In one embodiment of the present invention, a data 
delivering state machine, such as DESCRIP_FSM 106 and CONFIG_FSM 108 is implemented 
as a single state machine and in another embodiment a data delivery state machine is selected 
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from a plurality of state machines. 

The SETUP_FSM 102 of the SETUP Module captures and saves a standard 
Request carried on the USB and a state machine, INTERPRET FSM 104, interprets the saved 
standard Request. One or more data delivery state machines 106, 108, 110 release the 
information* requested in the Request for transmission over the USB to the Host device. 

The SETUP_FSM 102 has an interface with the following inputs and outputs as 
shown in FIGs. 6A and 6B. Table E. 



Inputs 


Outputs 


dpdout[7:01 


data[7:01 


elk 


interpret 


reset 


ACK? 


muxr2:01 




dp 1 write 




set token 




valid token 




usb endpoint_odpt[ 





Tabi.hE 



module, SRTTTP_Ffl M ( dndout . elk, reset, data, mux 
dp_1_write. Ret_tnken . val i d_token) : 



input [3:Q1 usb_endpt ,• 

input elk, reset, valid_token, set;_tQken, dp_l_wi;ite; 



output f7:Ql data: 
outpu,t interpre 



iterpret : 



reqf7;0l REQUEST , REQ, VALUE 1 , VALUE 2 , INDEX 1 , 

TNDEX2, LENGTH 1 

reg[3;Ql state, next_state; 



always @ (neqedqe elk) 

-if fflfit. tnlcen & valid token) state 



get SETUP: 



else state = next_state: 
always ® (posedqe dp_1_writ.fi or po sedae re set) 

beain: S ETUP_FSM 
if (reset) begin 

: next state = get_SETUP: 

interrup t <= Q: ■ 
§n_ 



else if (valid control endnoint and set_token) 
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qetJREQj 



interrupt <;= 0? 

Eml22 = dpdout [71 ; 

RRnrfi = .qi = {dndoutrei. dpdout rsil 

next st at.fi - qet_REQ f - 



begin 



get_VALUEl: begin 
VALUE 1 



REQUEST = dpdout: // f7:0l 
next state = get : VALUE 1 



dpdout : 



nfixt.jt.at.fi = get_VALUE2 : 

and 

VALUE 2 = dpdout? 
end 



gftt^LENGTHI : begin 

LENGTH 1 = dpdout ; 

= get_LENGTH2 : 
end 



get_LENGTH2: begin 

LENGTH 2 = dndout 



endcase 
endmodule 



nextjtate = aet_LENGTH2 : 

interpret <= 1: // enable interpret_F5M 

end 



Table F 



Internally, besides control circuitry, the SETUP = FSM has a registers 112, 1 14, 1 16-126 
for storing information about a Request. In particular, a register 112 stores the REQ_type, 
register 114 stores the REQUEST, registers 1 16-126 store the remaining bytes in the Setup 
Stage. The registers in the SETUP_FSM are written with data from the dpdout[7:0] bus 130 by a 
edge of the dp_lJL_write signal 132. The set z token signal 134 and valid_token signal 136 are 
used to start the SETUP_FSM 102. The mux[2:0] inputs 138 select one of the registers 112-126 
internal to the SETUP_FSM machine 102 to be output on to the data bus, data[7:0] 140. 

The INTERPRET_FSM 104 has the following inputs and outputs as shown in FIG. 

6G^Tahle G. 



Inputs 



Outputs Outputs 
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elk 


address 


valid 


reset 


config 


seir2:01 


datar7:01 


descrip 


VEND 


mux[2:01 


DIR. 


ERR 


interpret 


STD 


stall 




CLASS 





Tart f G 



module TNTEPPPET_FSM (elk, res fit. data, stall, mux, sel . 
address, confia . rffisnrip. DTP. STD. etc.) : 
•input f7:0l data: 
input interpret : 
output f2:0l mux, sel: 

output address, confia. descrip : //or other interpreted 
requests 

output DTP . STD. etc: 



// CLASS. VENDOR, etc. 



rea address, confia. descrip; 
reg [2:01 state, next_stat;e,- 



ite or interpret or data) begin 
)ret) begin 



INTERPRET 



stall = Q; 
mux = RECLtype; 
next^state = got JREQ^type ; 
.end 



DTP < = data f7l : 

case ({ dataffil. data f5l }) 

00 r STD = 1 : 

01 : CLAS = 1: 

10 : VEND = 1 : 

1 1 : EPP = 1 : 



next_state = a et_REQ; 

end 

aet_PEO : bea-in 
mux = sel^REQ? 

got. J?EQ ; 

got JREQ ; fregin 
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sel = \STATUS; 



status = 1 : 

next^state = 



end 



Q5: begin 



sel 



"ADDRESS ; 



address 



state = get^address 



find 



descrip = 1 : 



end 



Ofi; begin 
; sel 



*CONFTG: 



dn_nnnfia 



next_state = afi t_nonfia: 



OAs beain 
sel - 



interface = 1: 

next state = get interface: 



end 



defaults stal 1=1: 

endcase //data 
end 

qet_adriress : begin, 
mux = VALITE2 r 

■if (-interprets next_state = get_address: 

else next_state = 1NIT: 

grid 



end 

always @ (posedge elk) begin 

else state = nextjstate; 

end 

endmodule 



Tart f H 



The INTERPRETFSM 104 fTahleFH receives the Request from the SETUP_FSM 102 
over data bus 140 and is started when the SETUP_FSM 102 sets the interpret flag 142. During its 
operation, the machine, sets the DIR 144, STD 146, CLASS 148, VEND 150, and ERR 152 
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outputs depending on the content of the Request, and cycles through the binary values of the 
mux[2:0] 138 output to select the registers 112-126 of the SETUP_FSM 102. The 
INTERPRET FSM 104 machine also sets the sel[2:0] 154 to select for output one of several data 
delivery state machines, and enables one of those machines by means of an output, either address 
156 for the ADDRJSM 110, config 158 for the CONFIG_FSM 108, or descrip 160 for the 
DESC_FSM 106. 

The data delivery state machine DESCRIP_FSM 40 6106. in Table J. has the 
following inputs and outputs as shown in FIG. 6D Tah1e T . 



Inputs 


Outputs 


elk 


desc 


reset 




d datar7:01 




dp 1 read 




descrip 





Table T 



Module 

output [7;Q1 desc? 

dp^l^read, 




ige cfeiA 
if (desqrip) begirt 
case (state) 



: state = 1? 

£S4 



state = 2, 

end 




version? I (\ 



end 



3 : begin 
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rifisc = last byte 
state = last state: 



end 

last state: begin . . . 
endcase 
end 

endmodule 

Tari.f J 

The CONFKjJSM 108 and ADDRESS_FSM 110 have similar inputs and outputs as 
shown in FTG. 6C Tahle I A data delivery state machine, as shown in the figurejahk, receives a 
flag 156, 158, 160 from the INTERPRET_FSM machine 104 that starts the machine and the 
dp lj^read signal 162 that clocks the release of the data information from one of the delivery 
machines to the Dpdin[7:0] bus 164 via an intermediate bus 166, assuming a particular state of 
thesel[2:0] lines 154. 

Operation of the SETUP_FSM 

Referring to FTG. 6B Table F. the SETUP_FSM 102 bus data[7:0] connects to the 
INTERPRET_FSM 104 input bus 140 and the dpdout[7:0] bus is the input bus Dpdout[7:0] 130 
to the SETUP_FSM machine. As described above, a Request follows the token-data-handshake 
model. Therefore, the first packet in a Request is the setup token packet and this packet must be 
detected by the SETUP Module to get things started. (The setup token packet contains the ADDR 
and ENDP fields, which identify device and endpoint targeted for communication.) The endpoint 
in question is captured in the usb_endpt[3:0] register (not shown). 

When SETUP_FSM 102 detects the receipt of a token packet and if the valid z 
token is true, the state machine transitions from its idle state to the get_SETUP state to start 
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reading an eight byte data packet that follows the token packet. 

In the get_SETUP state, the first byte, REQ_type, of the data packet is stored on 
the edge of the dp_tL_write signal, dpdout[7] being stored in REQ[7], and dpdout[6:5] being 
stored in REQ[6:5]. 

Next, the SETUP_FSM transitions to the get_REQ state to capture the second byte, 
request on the edge of the dp_ll_write signal. 

Following this, the SETUP_FSM moves to the get_VALUEl and get_VALUE2 
states to capture the two value bytes, after which it moves to the getlNDEXl and get_INDEX2 
to capture the index bytes, and finally to the get_LENGTHl and get_LENGTH2 states to capture 
the length bytes. These bytes are also captured on the edge of the dp_iL_write signal. 

At this point, all of the bytes of the data packet of the SETUP stage of a Control 
Transfer have been captured and the interpret flag, is set to start the ESfTERPRET_FSM state 
machine. Also an ACK has been sent to the host to complete the SETUP stage of the Control 
Transfer. 

Operation of INTERPRETJFSM 

The INTERPRET_FSM 104 now operates to interpret the Request. The data[7:0] 
bus receives data from the SETUPFSM, the mux[2:0] 138 controls the output selector 170 of 
the SETUP_FSM 102 to select one of the internal registers 1 12-126 of the SETUP Z FSM 
machine 102. The sel[2:0] 154 bus controls the output selector 172 to select one of the data 
delivery state machines for output onto the intermediate bus 166. 

In state "20-H, the REQ_type value is assigned to the mux [2:0] register, stall is set 
to 0 and the machine advances to state gotJREQjype. The mux[2:0] register selects the input 
multiplexer channel, enabling the data on the data[7:0] input from the SETUP_FSM machine to 
be received by the INTERPRET_FSM. 

In the got_REQ state, the data[7] value is placed in the DIR output to control the 
direction of the transfer (to the host), and the outputs STD, CLASS, VEND, ERR are set 
according to the data[6:5] field of the Request byte after which the machine advances to the 
get_REQ ^state. 

In the sel_REQ state, the SELJREQ is copied into the mux[2:0] register and the 
machine advances to the got_REQ state in which the Request is parsed to determine what the 
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specific Request is. 

The INTERPRET_FSM, in the got_REQ state, considers the possible standard 
Requests, SET^STATUS, SETADDRESS, GET_DESCRIPTOR, GETCONFIGURATION, 
and GET JNTERFACE. 

If the Request is SET_STATUS, then the status variable is set to a one and the 
sel[2:0] register is set to the value of -ISTATUS-l. 

If the Request is SET_ADDRESS, then variable address is set to a one and the 
sel[2:0] register is set to the value of < ADDRESS\ The sel[2:0] register is used to select an 
appropriate output state machine, STATUS_FSM, DESCRIP_FSM, CONFIG_FSM or 
INTERFACE_FSM, into an output port dpdi[7:0]. ADDRESS_FSM generates the sel_ADDR 
signal to output the address from register in the SIE. If the Request is one of the get commands, 
then either descrip, do_config, or interface flag is set to a one and the sel[2:0] register is set to 
either the -J)ESCRIP-:, -ICONFIG-l, OR -JNTERFACE-1 values to select the respectively- 
named state machine, depending on which Request was received. For any other Request, the 
INTERPRET_FSM sets the stall flag to cause a stall in the handshake phase that follows the data 
phase of the Data Stage of the Control Transfer. 

If the Request was a SET ADDRESS, then the get z address state of the 
INTERPRET_FSM is entered, the mux[2:0] register is set to the VALUE2 parameter and if the 
interpret flag is true, the INTERPRET FSM machine spins in the get z address state. Otherwise, 
the INTERPRET_FSM machine goes to the INIT state and spins. 

One of several state machines can be started by the INTERPRETjFSM. It is 
assumed that the DESCRIP_FSM was set to run for the following description. 

Operation of the DESCRIP FSM 



The function of the DESCRDP_FSM 106 is to deliver a descriptor in the Data Stage 
of the Control Transfer. 

First, in state 0, the DESCRIP Z FSM 106 sends out a length byte over the desc[7:0] 
output port, and then proceeds to state 1, 

In state 1, a type byte is sent over the desc[7:0] port and the machine advances to 
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state 2. 

In state 2, a USB version byte is sent, and the machine advances to state 3, in 
which the machine sends the next byte of the descriptor. The state machine continues to advance 
through states 4-17 until the last descriptor byte is sent. The result is that a 17 byte descriptor is 
sent back to the USB host. Each byte that is sent back to the host, is sent on the occurrence of an 
edge of the dp_lJL_read signal, which functions as a clock that advances the state machine 
through its states. The sel[2:0] register from the INTERPRET_FSM has selected the 
DESCRIP_FSM for output which is also qualified with the usb_endpt[3:0] register, which holds 
an index value to an endpoint register from which the host is requesting the descriptor. The Setup 
token contained the endpoint that is the target for communication and this information was 
captured in the usb_ endpt[3:0] register. 

As mentioned above, a data delivery state machine is either a single state machine 
or a state machine selectable from a plurality of state machines, each having data for a specific 
configuration. 

FIG. 7 shows a plurality of selectable state machines 180 for implementing a 
configuration state machine in accordance with an alternative embodiment of the present 
invention. Each of the selectable machines 182-190 has a configuration descriptor, one or more 
interface descriptors for that configuration and one or more endpoint descriptors for each 
interface. While the length of a device descriptor has a minimum value, the length of a 
configuration descriptor can be long because the configuration descriptor is a concatenation of all 
the interface and endpoint descriptors for a configuration. It is preferred in the present invention, 
to implement a number of selectable configurations in a plurality of finite state machines, each of 
which has a fixed configuration descriptor, despite the length of the configuration descriptor. 
This avoids the need for multiple USB device interfaces when different configurations are 
required. The increase in cost caused by the added silicon area to implement a plurality of 
configuration state machines is more than offset by the costs of having multiple devices, one per 
configuration, each handling only a single, fixed descriptor. These costs include mask, NRE, 
testing, packaging, inventory and advertising. Thus, costs are effectively decreased and 
functionality is increased by designing multiple descriptors in silicon and allowing the device 
user to select the configuration. 
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As an example, a configuration that is suitable for an audio device includes a 
control endpoint, an interrupt-IN endpoint and two isochronous endpoints, one for IN data and 
one for OUT data. Another configuration for a mouse or joystick controller device includes a 
control endpoint and an interrupt-IN endpoint. A third configuration for a floppy disc controller, 
includes an interrupt endpoint, and bulk-IN and bulk-OUT endpoints. As described above, rather 
than having three different interfacing devices, all three configurations are implemented as 
selectable configurations in the same interfacing device. However, only one of the configurations 
is available for any given application. The host cannot negotiate a configuration with the USB 
device. Instead, the USB device simply makes available one of its configurations which is 
thereafter not alterable after the USB device has been configured for the particular application. 

FIG. 7£ shows one of the selection mechanisms. This selection mechanism 
includes a set of user-configurable pins 192 for encoding a binary number as a selection code and 
a data selector 194 to select one of the plurality of configuration state machines 182-190. 

FIG. &2 shows a combined selection mechanism. This selection mechanism 
includes a writable register 196 that holds a selection code and a decoder 200 whose outputs 202 
control data selector or equivalent circuit 194 to select one of the state machines 182-190 of FIG. 
7. Multipl e xo r Multiplexer 198 is not required if the writable register 196 is used instead of the 
user-configurable pins 192. The combined selection mechanism combines the user-configurable 
pins and the writable register and includes additional multipl e xo r multiplexer 198 for selecting 
either the selection code from either source. In the combined selection mechanism, an additional 
bit 204 is used to control selection by the additional multipl e xor - multiplexer 198. In the preferred 
implementation, the extra bit 204 defaults to a value that selects the external pins 192 as the 
source of the selection code 195. In an implementation that connects a microprocessor such as an 
8051 or equivalent to the USB device interface, the preferred location of the writable register 196 
is the special function register file of the 8051 -type microprocessor. 

As described above, either of the data delivering machines, DESCRIP_FSM 106 in 
FIG. 5, CONFIG_FSM 108, is implemented, in accordance with the present invention, as a state 
machine selected from a plurality of selectable state machines. FIG. 9& shows a case in which 
both the DESCRIP_FSM and the CONFIG_FSM are implemented by a plurality of selectable 
state machines. Sel #1 selects a first combination 206 of the device descriptor and configuration 
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state machines and Sel #N selects the nth combination 208 of the these state machines. If both 
the DESCRIP_FSM and CONFIG_FSM state machines are implemented in this fashion, 
selection of a state machine from each plurality of state machines comes from the same selection 
source 204, thereby coordinating a compatible selection of device descriptor from the 
DESCRIP_FSM with a configuration descriptor from the CONFIG_FSM state machine. 

FIG. W£ shows an application of an embodiment of the present invention. In this 
application the function engine 220 is a CY325++ device that has the functionality required for 
driving a LCD display 222. In accordance with the present invention, the endpoint register 224 in 
the USB_ctl block 226 points to a code buffer 228 which receives commands requesting the 
display of data on the LCD display device 222. A state machine 230 handles the interface 
between the code buffer 228 and the CY325++ device 220. In this application, only an OUT 
endpoint and a COMMAND endpoint are required because the display is a write-only peripheral. 

FIG. shows an expanded application of an embodiment of the present 
invention. In this application the function engine is still the CY325++ 220, however there are two 
LCD windows 222 to be supported by the function engine. For this functionality, a command 
endpoint (code) 228, and two OUT endpoints (datal 240 and data2 242) are required along with 
a configuration module (SETUP) 100. The command endpoint receives commands in the code 
memory and a finite state machine FSM 230 interprets the commands to operate the interface of 
the CY325++ 220. The datal 240 and data2 242 endpoints receive data for the DATA1 and 
DATA2 portion of the LCD display 222 respectively. The state machine 230 operates the 
CY325++ interface so that internal registers of the CY325++ device 220 properly receive the 
commands and display data. 

Although the present invention has been described in considerable detail with 
reference to certain preferred versions thereof, other versions are possible. Therefore, the spirit 
and scope of the appended claims should not be limited to the description of the preferred 
versions contained herein. 
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CLAIMS 

What is claimed is: 

1 . A device controller for establishing a communication channel between a slave device 
and a host device, the slave device including the device controller and a function engine, the 
slave device and host device being connected to a packet-switched serial bus, the device 
controller comprising: 

a serial interface engine having a serial port that connects to the serial bus and a 
data port, the serial interface engine for generating and interpreting packets on the serial bus and 
transferring data between the serial bus and the data port; and 

an interfacing device connected between the data port of the serial interface engine 
and the function engine to transfer data between the serial interface engine and the function 
engine, the interfacing device including a configuration module for configuring the 
communication channel between the slave device and the host device. 

2. A device controller as recited in claim 1, wherein the interfacing device further 
includes: 

at least one register that stores configuration information relating to the 
communication channel between the slave device and the host device; and 

at least one memory that holds operating data relating to the communication 

channel; 

wherein the configuration module is connected to the at least one memory and 
includes a plurality of finite state machines that are operative to receive and respond to a request 
from the host device. 

3. A device controller as recited in claim 2, wherein the configuration module includes: 

a first state machine for receiving and storing a request packet from the host, the 
first state machine having an output line carrying a signal indicating that a request packet has 
been stored and is available to be interpreted; 

a second state machine for accessing and interpreting the request packet in 
response to the output signal of the first finite state machine, the second state machine having at 
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least one output line for carrying a data transfer signal, and activating the data transfer signal 
based on the interpretation of the request packet; and 

at least one data transfer state machine for transferring requested data in response 
to an active data transfer signal. 

4. A device controller as recited in claim 3, 

wherein the request is a GET ^DESCRIPTOR request; and 

wherein the data transfer state machine delivers at least a seventeen-byte descriptor 
to the serial interface engine to be sent to the host device. 

5. A device controller as recited in claim 3, 

wherein there are a plurality of data transfer state machines; and 

wherein only one data transfer state machine receives an active data transfer signal. 

6. A device controller as recited in claim 3, 

wherein the type of request interpreted by the second state machine is not 
supported; and 

wherein the second state machine indicates to the serial interface engine to issue a 
stall packet to the host. 

7. A device controller as recited in claim 1, further comprising: 

at least one endpoint associated with the function engine; and 

a group of state machines associated with the function-engine endpoint. 

8. A device controller as recited in claim 7, 

wherein the endpoint includes an endpoint register having a type field for 
indicating the type of data transfer the endpoint supports; and 

wherein the type field is accessible by at least one of the state machines in the 
group associated with the endpoint. 

9. A device controller as recited in claim 7, 
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wherein the group of state machines has a clock line for carrying a clock signal; 
wherein the serial interface engine detects a start-of-frame condition on the serial 

bus; and 

wherein the clock signal for the group of state machines is derived from the start- 
of-frame condition. 

10. A device controller as recited in claim 7, 

wherein the function-engine endpoint is an OUT-type endpoint; and 

wherein the group of state machines associated with the function engine endpoint 

includes: 

a data storage state machine that holds data sent from the host for the 

function 

engine; and 

a command state machine that interprets the stored data in the data storage 
machine to operate the function engine. 

1 1 . A device controller as recited in claim 10, wherein the function engine includes a 
D/A converter. 

12. A device controller as recited in claim 7, 

wherein the function-engine endpoint is an IN-type endpoint; and 

wherein the group of state machines associated with the function engine endpoint 

includes a data collecting state machine that holds data sent from the function engine for the host; 

and 

a command state machine that interprets commands from the host to read the data 
in the data collecting state machine. 

13. A device controller as recited in claim 12, wherein the function engine includes an 
A/D converter. 
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14. A device controller as recited in claim 7, wherein the endpoint has a register with a 
bit indicating whether the endpoint is ready to communicate with the host, a not-ready indication 
instructing the serial interface engine to send an auto-NAK to the host. 

15. A device controller as recited in claim 14, wherein at least one of the state machines 
in the group determines that the endpoint is ready for communication with the host and sets the 
bit in the register to indicate that the endpoint is ready. 

16. A device controller as recited in claim 1, further comprising: 

at least two endpoints associated with the function engine; and 

a group of state machines associated with each function-engine endpoint. 

17. A device controller as recited in claim 16, 

wherein the first endpoint associated with the function engine is an OUT-type 

endpoint; and 

wherein the group of state machines associated with the function engine endpoint 
includes a data transfer state machine which receives commands from the host for controlling the 
operations of the second endpoint associated with the function engine. 

18. A device controller as recited in claim 1, further comprising 

at least endpoint associated with the function engine; and 

a memory buffer having a plurality of storage locations and associated with the 

endpoint; and 

an endpoint register having an index field for addressing the memory buffer. 

19. A device controller as recited in claim 18, further comprising a counter that is updated 
every time one of the plurality of the storage locations in the memory buffer is accessed. 
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ABSTRACT OF THE DISCLOSURE 
A device controller for connecting a function engine that supports an application to 
a packet-switched serial bus to which a host device is connected. The interface device includes a 
serial interface engine for transferring packets between the serial bus and the function engine and 
an interfacing device that employs a plurality of state machines in a device configuration module. 
The state machines of the device configuration module operate to configure the interfacing 
device and make that configuration known to the host. Additionally, for each interface of the 
function engine the rethat is a group of state machines, at least one of which transfers data 
between the serial interface engine and the function engine and at l e ast on e of which r e c e iv e s 
commands from the host for op e rating the function e ngin e. In one embodiment the serial bus is 
the USB and the configuration module conforms to the configuration protocol of the USB. As an 
additional aspect of the invention multiple configurations are supported by the device 
configuration module. These multiple configurations are user-selectable configurations that can 
only be changed at configuration time. Once configured the device controller maintains the 
confi gurati o n con fi gurati on s through out its operation until reset and re-configured. Multiple 
configurations are provided to minimize the number of different device controllers needed in 
inventory and to provide a single, flexible device for various controller applications. 

87325.1.17 
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